Real-time systems, such as onboard or distributed systems, for example, support applications that are dependent on compliance with time constraints of the environment. In particular, in what are known as “strict” real-time systems, where satisfaction of these time constraints is critical, processing operations are grouped into different execution units that communicate among one another. Implementation of these communications between execution units (or tasks) is dependent on the underlying real-time operating system (denoted by the acronym RTOS), which is used for executing multitask applications. There are two approaches for implementing such an implementation of intertask communications:
in a first approach, the RTOS explicitly implements necessary data copies for the use of memory copy functions (for example “memcpy”);
in a second approach, the RTOS delegates to a direct memory access controller (or DMA) the implementation of necessary data transfers and is informed only of termination of the transfers.
The second approach allows the processor to be relieved of execution of data transfers and allows additional processor time to be freed from executing application processing operations. Nevertheless, the delegation of data copies to the DMA controller has a fixed initial cost that is independent of the size of the data to be copied and of linking of the necessary DMA requests, which is dependent on the memory organization of the executed application. Thus, if the use of a DMA controller for transferring data proves successful from small or medium data sizes, this is not the case for very small data sizes. Moreover, the use of such a solution requires setup of a “contract” between the DMA controller responsible for copying the data and the designer of an application in order to ensure that the memory areas that are the source and destination for memory movements can no longer be modified by an application processing operation during the implementation of the transfer by the DMA controller.
Various solutions are known for controlling interference due to the use of a DMA in a strict real-time system by a task for communicating with a peripheral area. Thus, some solutions are geared to the impact of the use of a task performing an input/output (I/O) via a DMA on “worst case” execution times for the tasks that are executed on a processor resource (for example in Tai-Yi Huang and Chih-Chieh Chou and Po-Yuan Chen. Bounding the Execution Times of DMA I/O Tasks on Hard-Real-Time Embedded Systems. 9th International Conference on Real-Time and Embedded Computing Systems and Applications, RTCSA 2003, Taiwan, February 2003). In a strict real-time system, these “worst case” execution times must indeed be known. In point of fact, a DMA can be programmed in CPU (acronym for “central processing unit”) cycle steal mode for use of the memory bus, which can cause memory access conflicts for the processor and hence delay execution of application processing operations. Other solutions relate to the use of a DMA controller in sequencing tests for strict real-time tasks, either explicitly through the inclusion of an additional task or by increasing worst case execution times for each task (C. Pitter and M. Schoeberl. Time Predictable CPU and DMA Shared Memory Access. International Conference on Field Programmable Logic and Applications, pp. 317-322, August 2007). Nevertheless, these solutions do not relate to the use of a DMA controller for performing data transfers having time constraints between communicating real-time tasks.
Other solutions relating to optimization of the order of DMA requests in relation to their deadline are known. By way of example, U.S. Pat. No. 7,917,667 B2 describes a method for computing the priority of the various DMA requests and therefore their order of execution by the DMA controller. Computation of the priority of a DMA request is performed by hardware and/or by software, by relying particularly on the initially estimated time, the time taken and an arbitrary margin. This patent relates particularly to DMA requests in which a deadline is specified. Such a method allows modification of the priority of a DMA request on the basis of its urgency (i.e. its real progress in relation to its deadline) in relation to other DMA requests in progress. Nevertheless, this document does not tackle data transfers between communicating real-time tasks implemented by DMA requests.
Another solution proposed in U.S. Pat. No. 3,925,766 A relates to a DMA controller comprising a periodic surveillance mechanism for the use of a bus shared between computation resources and peripherals. This surveillance of the use of a shared bus allows authorization or rejection of access to the bus for DMA requests from or to peripherals so as to share the bus proportionally in relation to the priority of the various DMA requests. The famine situations that can exist in a conventional DMA controller, in which the priority of transfers is fixed statically and used to define the order of execution of transfers, are thus avoided. This mechanism of surveillance of the use of a bus is also used to detect whether or not the transfer is part of a real-time processing operation and consequently to adapt the granularity of the data copied by a DMA request.
Other solutions relating to optimization of DMA data transfers relate to hardware extensions at DMA level in order to link the triggering of DMA requests to an event or to dates. By way of example, WO 2007003986 proposes a method for programming temporarily cyclic DMA tasks in order to perform data transfers (method for constant cycle DMA transfer). A temporarily cyclic DMA task is a DMA task having a defined periodicity, and each instance of this periodic task is made up of a set of DMA requests, the number of DMA requests being dependent on the total size of the datum to be transferred and on the quantity of data that is transferrable in a DMA request. The use of such types of DMA tasks for transferring data does not require interaction for programming the DMA controller in each cycle. The priority of a DMA request can be dynamically adapted on the basis of the deadlines associated with the transfers, if an arbitration policy taking account of the deadlines of the transfers is used. This document particularly describes the use of three dates comprising the value of the current time, the start date for initialization of the transfer and a deadline. Breach of the deadline can be used by the DMA controller or a computation resource to implement various strategies, such as, by way of example, to increase the priority of a DMA request, to stop a DMA task, to force execution of DMA requests, etc. Like the U.S. Pat. No. 7,917,667 B2, this method allows a priori construction of a system in which it is possible to show that DMA requests will be terminated before a certain deadline. Nevertheless, this solution does not solve the problem of data transfer between communicating real-time tasks implemented by DMA requests. Another solution proposed in the patent U.S. Pat. No. 8,266,340 B2 describes a hardware extension at DMA controller level in order to include a hardware counter of a measuring time, a value comparator for the time counter and a state comparator in relation to acquisition of the state of a peripheral using DMA. On the basis of this information, after a match has been obtained between the time counter and the value indicated in the value comparator of the time counter, triggering of one or more DMA requests by the DMA controller is determined by the obtainment of a match between the state of the peripheral and the value indicated in the state comparator. Such a method allows DMA requests to be triggered without the need for logic operations of polling type, and therefore the intervention of a computation resource, thus avoiding an additional load at the level of this computation resource.
Other solutions concerning the optimization of DMA data transfers relate to hardware extensions in order to safeguard the execution of DMA requests. By way of example, the patent U.S. Pat. No. 7,523,229 B2 describes a solution in which a hardware extension for access control is associated with an input/output controller, equipped with a DMA controller, and is programmable via two types of registers. The first type of register is accessible by means of any application process in order to specify the destination or source address in a DMA request between the input/output peripheral and the memory of the system (transfer of memory/peripheral type). The second type of register describes the memory rights applicable in the memory area specified in the first type of register. This second type of register can be used only in execution mode, referred to as “privileged”, by a computation resource, that is to say by a trusted code. The input/output controller extended in this manner can then detect any unauthorized memory access attempt at the time of a DMA request and can stop execution thereof. In yet another approach, which is described in the patent US 2005/0165783 A1, a hardware extension is proposed in which the logic for controlling memory access operations by the various masters on a bus (thus potentially including DMA controllers) is situated at the access of the bus (rather than at the input/output controller as in the patent U.S. Pat. No. 7,523,229 B2). The table for describing memory access rights is dependent on a privileged process, typically the operating system, and is indicated on system startup. Similarly, the patent application WO 2009138928 A1 describes another organization for the hardware extension necessary via use of the conventional memory protection mechanism in an architecture not only for the computation resources but for all masters connected to the memory system. Thus, any memory access, whether from a computation resource or from a DMA controller, is monitored before being either authorized or rejected.
Thus, there are a certain number of solutions allowing the use of a DMA to be taken into account in the dimensioning and sequencing of real-time systems, and/or making it possible to ensure that data transfers by a DMA controller do not adversely affect the real-time constraints of the data, and/or to safeguard DMA data transfers. When the approach used to implement intertask communications relies on a DMA controller, there is great freedom for transferring the data between activation and the deadline of communicating tasks, which can result in limited performance of the real-time system, in overdimensioning of the necessary resources or in compromise of the system if DMA requests are not executed appropriately and in a safeguarded manner.